Access control systems are frequently used to control unauthorized access to buildings or anything else to which access is limited, e.g., the operation of certain machinery such as baggage carousels. Such systems may include card readers, biometric readers, and sensors to sense, for example, when a door or window is opened or closed.
As shown in FIG. 1, most conventional systems 100 include a server 102, a database 103, and several units 104, 106, 108 for interacting with readers 110, inputs 112, or outputs 114. Inputs may include, for example, signals from sensors indicating status such as “door open” or “door closed.” Outputs may include, for example, signals to relays, e.g., for opening a door.
In most conventional systems 100, the functions for controlling readers, inputs, and outputs are specifically and fixedly programmed and housed in physically separate units 104, 106, and 108. Each unit also independently connects to the server 102. Thus, at a particular location, e.g., a door, three physically separate box-like units are required: one to connect to a card reader, one to connect to inputs from the door (e.g., sensors to sense if the door is in an open or closed state), and one to connect to outputs for controlling the door operation (e.g., to release the lock). Obviously, this consumes considerable wall space or other real estate.
The functionality of readers, inputs, and outputs are fixedly programmed in firmware included in each unit 104, 106, 108 as shown in FIG. 1. The firmware is specific to the function the unit is to perform and the field devices expected to be coupled to the unit. Hence, for a particular brand of card reader, the reader unit will include firmware programmed to control that particular card reader brand. Moreover, while each unit may have multiple field devices (e.g., multiple readers) coupled to it, each port for those field devices is dedicated to and programmed to support that particular device. For instance, if a port on an output unit 108 is programmed to be coupled to a lock, only a lock can be coupled to that port.
Accordingly, if a change to the system needs to be made, either the entire unit 102, 104, 106 must be replaced, or at a minimum, the EPROM storing the firmware usually needs to be removed and replaced with one with new programming. Frequently, this EPROM change may also require changes to the surrounding electronics and many parts of the system may also need to be reconfigured manually. Thus, upgrading such a system can be cumbersome. For large systems, such as those in airports, hospitals, or other large buildings, these upgrades can be quite costly and can temporarily compromise building security.
As a result of the fixed nature of these systems, these systems tend to be fully designed for the exact user need at installation. And while the ability to have a customized system may initially be desirable, the fixed nature of the system tends to make it burdensome to expand or change later.
Conventional systems rely on server 102 as the “brains” of the system, housing almost all relevant software as well as the majority of system memory. The server 102 issues commands to control the operation of each unit 104, 106, 108. Only server 102 has access to the data in database 103. Little or no information about access privileges is stored in units 104, 106, 108. Thus, if communication with the central server is interrupted, many of these systems cannot perform any access control functions or perform such functions at a severely degraded level, frequently losing alarm condition information.
Conventional systems also tend to operate on slow networks based on RS-232 or -485 because they frequently must be compatible with old legacy systems. Because the units are designed for use with these slower networks, if use of a faster network, such as an ethernet network, is desired, an interface 116 must be used between the RS-232 or -485 signals and the ethernet signals. Still a system can only operate as fast as its slowest part (RS-232 or -485 speeds).
Further, most systems currently available are proprietary and not based on open architectures. They usually have proprietary networking architectures and communications protocols, databases and file formats, operating systems, graphical user interfaces, device drivers, or application program interfaces (APIs) for use with various field devices. Thus, the system will only operate with the manufacturer's own equipment and software or a limited subset of equipment and software available from selected suppliers. Accordingly, if the system is unreliable, does not meet end-user expectations, or if the user simply wants to use equipment from another supplier or share information from another database, the user will frequently be unable to. In other words, end users are at the mercy of system manufacturers.
Accordingly, a system that is more reliable, modular, faster, scalable, and easily upgradable is desirable.